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Abstract 

Periodic control systems used in spacecrafts and automotives are usu- 
ally period-driven and can be decomposed into different modes with each 
mode representing a system state observed from outside. Such systems 
may also involve intensive computing in their modes. Despite the fact that 
such control systems are widely used in the above-mentioned safety-critical 
embedded domains, there is lack of domain-specific formal modelling lan- 
guages for such systems in the relevant industry. To address this problem, 
we propose a formal visual modeling framework called MDM as a concise 
and precise way to specify and analyze such systems. To capture the tem- 
poral properties of periodic control systems, we provide, along with MDM, 
a property specification language based on interval logic for the descrip- 
tion of concrete temporal requirements the engineers are concerned with. 
The statistical model checking technique can then be used to verify the 
MDM models against desired properties. To demonstrate the viability of 
our approach, we have applied our modelling framework to some real life 
case studies from industry and helped detect two design defects for some 
spacecraft control systems. 



1 Introduction 

Control systems that are widely used in safety-critical embedded domains, such 
as spacecraft control and automotive control, usually reveal periodic behaviours. 
Such periodic control systems share some interesting features and characteristics: 
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period = 32ms „„„ (SB . L200l) 




Figure 1: MDM: An (Incomplete) Example 



• They are mode-based. A periodic control system is usually composed of a 
set of modes, with each mode representing an important state of the sys- 
tem. Each mode either contains a set of sub-modes or performs controlled 
computation periodically. 

• They are computation- oriented. In each mode, a periodic control system 
may perform control algorithms involving complex computation. For in- 
stance, in certain mode, a spacecraft control system may need to process 
intensive data in order to decide its space location. 

• They behave periodically. A periodic control system is reactive and may 
run for a long time. The behaviour of each mode is regulated by its own 
period. That is, most computations are performed within a period and 
may be repeated in the next period if mode switch does not take place. 
Mode switch may only take place at the end of a period under certain 
conditions. 

Despite the fact that periodic control systems have been widely used in areas 
such as spacecraft control, there is lack of a concise and precise domain specific 
formal modelling language for such systems. In our joint project with China 
Academy of Space Technology (CAST), we have started with several existing 
modelling languages but they are either too complicated therefore require too 
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big a learning curve for domain engineers, or are too specific/general, therefore 
require non-trivial restrictions or extensions. This motivates us to propose a new 
formal but lightweight modelling language that matches exactly the need of the 
domain engineers, the so called Mode Diagram Modelling framework (MDM). 

Although the proposed modelling notation MDM can be regarded as a variant 
of Statecharts [7], it has been specifically designed to cater for the domain- 
specific need in modelling periodic control systems. We shall now use an example 
to illustrate informally the MDM framework, and leave the formal syntax and 
semantics to the next section. As shown in FigQ] the key part of a MDM model 
is the collection of modes given in the mode level. Each mode has a period, 
and the periods for different modes can be different. A mode can be nested and 
the transitions between modes or sub-modes may take place. A transition may 
be enabled if the associated guard is satisfied. In MDM, the transition guards 
may involve complex temporal expressions. For example, in the transition from 
mode G2 to mode m6, in addition to the condition SK12=10, it also requires 
that the condition gm—2 has held for 40s, as captured by the duration predicate. 

An MDM model is presented hierarchically. A mode that does not contain 
any sub-modes (termed a leaf mode) contains a control flow graph (CFG) en- 
capsulating specific control algorithms or computation tasks. The details of 
CFGs are given in the CFG level. The CFGs may refer to modules (similar to 
procedures in conventional languages) details of which are given in the module 
level. 

To support formal reasoning about MDM models, we also provide a property 
specification language inspired by an interval-like calculus [4], which facilitates 
the capture of temporal properties system engineers may be interested in. Two 
example properties are listed in Fig [I] The property PI says that "whenever 
the system enters the m4 mode, it should stay there for at least 600s". The 
formal details of the specification language is left to a later section. 

To reason about whether an MDM model satisfies desired properties speci- 
fied by system engineers using the property specification language, we employ 
statistical model checking techniques [HI [20]. Since MDM may involve complex 
non-linear computation in its flow graph, the complete verification is undecid- 
able. Apart from incompleteness, statistical model checking can verify hybrid 
systems efficiently [2]. Our experimental results on real life cases have demon- 
strated that the statistical model checking can help uncover potential defects of 
MDM models. 

In summary, we have made the following contributions in this paper: 

• We propose a novel visual formal modelling notation MDM as a concise 
yet precise modelling language for periodic control systems. 

• We present a formal semantics for MDM and a property specification lan- 
guage to facilitate the verification process. 

• We develop a new statistical model checking algorithm to verify MDM 
models against various temporal properties. 

• We have carried out real life case studies to demonstrate the effectiveness 
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md ::= (Var + , Mode + , Module + ) 
Mode ::= (name, period, initial, Body, Transition^) 
Body ::= Mode+ j CFG 
Transition ::= (source, guard, priority, target) 
Module ::= (name, Vr, Vo, CFG) 
(a)MDM 



SExpr : 


:= Const | Var | / (n) (SExpr. . .) 




BTerm : 


:= true false p (n) (SExpr . . .) 




IExpr : 


:= (after | duration)(_BTerm, SExpr) 




GTerm : 


:— IExpr | BTerm 




BExpr : 


:= BTerm | -.BExpr \ BExpr V BExpr 


BExpr A BExpr 


guard : 


:= GTerm \ -^guard \ guardW guard \ gi 


Lard A guard 



(b) Expressions and Guards 



CFG 


=df 


stmts 


stmts 


=df 


pStmt | cStmt 


pStmt 


=df 


aStmt | call name | skip | 


aStmt 


=df 


x := SExpr 


cStmt 


=df 


stmts; stmts \ while BExpr do stmts 






if BExpr then stmts else stmts 






(c) CFG 




Fit 


;ure 2: The Syntax of MDM 



of the proposed framework. We have managed to discover some design 
defects of a real spacecraft control system. 

The rest of this paper is organized as follows. Section [5] presents the formal 
syntax and semantics of MDM. Section [3] introduces our interval-based property 
specification language and its semantics. The statistical model checking algo- 
rithm for the MDM is developed in Section 2) Implementations and case studies 
are presented in Section O followed by related work and concluding remarks. 

2 The MDM Notations 
2.1 The Syntax of MDM 

We briefly list its syntactical elements in Fig. Efa). An MDM is composed of 
a list of modes (Mode + ) and modules (Module + ), as well as a list of variables 
(Var + ) used in those modes and modules. 

Intuitively, a mode refers to a certain state of the system which can be 
observed from outside. A mode has a name, a period, a body and a list of 
transitions. For simplicity, we assume all mode names are distinct in an MDM 
model. The mode period (a real number) is used to trigger the periodic behavior 
of the mode. The mode body can be composed of either a control flow graph 
(CFG), prescribing the computational tasks the system can perform in the mode 
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in every period, or a list of other modes as the immediate sub-modes of the 
current mode. If a mode has sub-modes, when the control lies in this mode, 
the control should also be in one of the sub-modes. A leaf mode does not have 
sub-modes, so its body contains a CFG. A mode is either a leaf mode, or it 
directly or indirectly has leaf modes as its sub-modes. A mode is called top 
mode if it is not a sub-mode of any other mode. The CFG in a leaf mode 
is the standard control flow graph, which contains nodes and structures like 
assignment, module call, conditional and loop. It also supports function units 
like the ones in conventional programming languages. The syntax of CFG is 
presented in Figure [^c). 

A module encapsulates computational tasks as its CFG. Vj specifies the 
set of variables used in the CFG, while Vo is the set of variables modified in 
the CFG. A module can be invoked by some modes or other modules. As a 
specification for embedded systems, recursive module calls are forbidden. 

A transition (from Transition^) specifying a mode switch from one mode to 
another is represented as a quadruple, where the first element is the name of 
the source mode, the second specifies the transition condition, the third is the 
priority of the transition and the last element is the name of the target mode. 
The MDM supports mode switches at different levels in the mode-hierarchy. The 
transition condition (i.e. guard) is defined in Fig. dth). A state expression can 
be either a constant, a variable, or a real-value function on state expressions. A 
boolean term is either a boolean constant, or a predicate on state expressions. 
There are two kinds of interval expressions, after and duration. These interval 
expression are very convenient to model system behaviors related with past 
states. A guard term can be either an interval expression, or a boolean term. A 
guard is the boolean combination of guard terms. To ensure the mode switches 
deterministic, we require that the priority of a transition should be distinguish 
with others in the same mode chain: 

Vto G Mode -Vii,i2 G outs(super_modes(m<i, m)) ■ t\ ^ t% =>• prio(ti) ^ prio(t2) 
The functions super_modes(m<i, m) and outs(mlist) will be defined later. 

2.1.1 Auxiliary Definitions 

Given an MDM md ::= (Var + , Mode + , Module + ), we introduce two auxiliary re- 
lations: 

Contains(md) C Modes x Modes for mode-subsume relation and 
Trans(md) C Modes x Int x guard x Modes for mode-switch relation. 

Given a mode m = (n,per,ini,b,tran) and a transition t — (m, g,pri,m'), 
we define these operations/predicates: 

period(m) = per isJnitial(m) = ini CFG(m) = b 

prio(t) = pri guard(t) = g source(t) = m target(t) = m! 
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ai-...-a n |= b o n \= b 

ai-...-a n \= ->g ->(ai-...-(7„ \= g) 

°n \= gi V g-2 ai-...-a„ \= gi or oi-...-a„ \= gi 



ai-...-a„ \= gi A g 2 O a\-...-o n |= gi and a\-...-a n |= gi 

ai-...-a n |= duration(6, I) <r n (l) = v A 3i<n ■ (<Ji(ts)+v < a n (ts)/\ 

o i+ i(ts)+v > a n (ts) A Vi<j<n ■ <7j(b) = true) 
fTl • ...'(7 n |= after(6, 1) <^ o n {l) = v /\3i<n • (oi(ts)+v < a n (ts)A 

cr i+1 (ts)+u > a n (ts)) A ai(b) = true) 



Table 1: The Interpretation of Guards 
We also define the following auxiliary functions: 

super_modes(m<i, m) = (m 1; m 2 , . . . , m fc ), where 

TOfc = m A mi G TopModes(md) A Vl<i<fc • (m,_i, mj) G Contains(md) 
and m€TopModes(md) = me Modes (md)A^3m' ■ [m! 1 m)^Contains(md) 

up_modes(m<i, m, fc) = {nij | m t G super_modes(m<i, m) A mod (fc, ^'"^"^ ) = 0} 

sub_mode(mrf, m) = m', where (to, to') G Contains A isJnitial(m') 

outs(mfci) = Umemtoti* I t e A source(t) = m} 

The function super_modes(mrf, to) retrieves a sequence of modes from a top mode 
to to using the Contains relation. The set TopModes(md) consists all the modes 
which are not sub-modes of any other mode. The function up_modes(mrf, m, k) 
returns those modes in super_modes(m<i, m) whose periods are consistent with 
the period count k. MDM requires that the period of a mode should be equal to 
or multiple to the period of its sub-modes. The function sub_mode(m(i, to) re- 
turns the initial sub-mode for a non-leaf node m, and the predicate isJnitial(m') 
means that the sub-mode m! is the initial sub-mode in its hierarchy. The func- 
tion outs(mlist) returns all outgoing transitions from modes in mlist. 

2.2 The Semantics 

In order to precisely analyze the behaviors of MDM, for instance, model check- 
ing of MDM , we need its formal semantics. In this section, we present the 
operational semantics for MDM. 

2.2.1 Configuration 

The configuration in our operational semantics is represented as (md, m, l,pc, k, E) , 
where 

• md is the MDM, and to is the mode the system control currently lies in. 

• I G {Begin, Execute, End} specifies the system is in the beginning, middle, 
or end of a period. 
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• pc€ where C = J\f U {Start, Exit, _L} is the program counter to execute 
the control flow graph. J\f is used to represent the nodes in control flow 
graphs and Start, Exit denote the start and exit location of a control flow 
graph respectively. If the current mode is not equipped with any flow 
graph, we use the symbol 1 as a placeholder. 

• The fourth component k records the count of periods for the current mode. 
If the system switches to another mode, it will be reset to 1. The period 
count is used to distinguish whether a super-mode of the current mode is 
allowed to check its mode switch guard. 

• £ is a list of states of the form E' ■ a, where a denotes the current state 
(cr £ State = Vars— >U) and £' represents a history of states. 

Guards The evaluation of a transition guard may depend on the current state 
as well as some history states. Table Q] shows how to interpret a guard in a given 
sequence of states. The symbol ts is the abbreviation of the variable timestamp. 
The guard duration(6, 1) evaluates to true if the boolean expression b has been 
true during the time interval I up to the current moment. The guard after(6, 1) 
evaluates to true if the boolean expression b was true the time interval / ago. In 
this table, & is a pure boolean expression without interval expressions and I is a 
state expression. 

2.2.2 Operational Rules 

The operational rules for MDM are given in Table [2] Here we adopt a big-step 
operational semantics for MDM, which means that we only observe the start 
and end points of a period in the current mode, while the state changes within 
a period are not recorded. This is reasonable since in practice engineers usually 
monitor the states at the two ends of a period to decide if it works well. In the 
rules, we make use of an auxiliary function execute to represent the execution 
results for the mode in one period. 

execute : CTQ(V) x C x State x R + — > C x State 

It receives a flow graph, a program counter, an initial state and the time per- 
mitted to execute and returns the state and program counter after the given 
time is expired. Its detailed definition is left in the report [18]. We now explain 
the operational rules: 

1. (enter). When the system is at the beginning of a period, if the current 
mode m has sub-modes, the system enters the initial sub-mode of m. 

2. (detect). When the system is at the beginning of a period, if the current 
mode m is a leaf mode, the system updates its state by sampling from sen- 
sors. The function sampling represents the side-effect on variables during 
sensor detection. The period label / is changed to be Execute, indicating 
that the system will then perform computational tasks specified by the 
control flow graph of m. 
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(enter) 

(detect) 
(execute) 

(continue) 
(repeat) 

(switch) 



CFG(m) = _L 

(md,m, Begin, _L,fc,E) — > (md,m', Begin, pc',k,T,) 



where m' = sub_mode(?nd, m) and pc' 



CFG(m) / _L 



, _ J_L, if CFG(m') = -L 
j,SWi, if CFG(m') / -L 



(md, m, Begin,pc, k, E • a) — !> (md, m, Execute, pc, k, E • sampling(cr)) 

e:rec«ie(CFG(m),pc, <r, period(m)) = (pc ,a') 
(md,m, Execute, pc, fc, E-cr) — 5- (md,m, End,pd , fc, E') 
where E' = E ■ cr'[ts cr(ts) + period(m)] 

(rati, m, i?nd, pc, fc, E) — !> (md, m, Execute, pc, k, E) 
Vt G outs(up_modes(md, m, fc)) • E ^= guard(t) 
(md, m, End, Exit, k, E) — > (md, m, Begin, Start, fc+1, E) 

3t £ outs(up_modes(md, m, k)) ■ E |= guard(t)A 

Vt'€outs(up_modes(md, m, k))-{t] ■ (E ty= guard(t') V prio(t')<prio(t)) 

(md, m, End, Exit, k, E) — > (md, m', Begin, pd ', 1, E) 

, x , / f-L, if CFG(m') = -L 
where m = target(t) and pc = < 

W \5*iari, if CFG(m') / _L 



Table 2: Operational Semantic Rules for MDM 



3. (execute). This rule describes the behaviors of executing CFG of the 
leaf mode m. The function execute is used to compute the new state a' 
from a. The computation task may be finished in the current period and 
pd = Exit holds or the task is not finished and the program counter points 
to some location in the control flow graph. The value of the timestamp 
variable ts in a' is equal to its value in state a plus the period of the mode 

TO. 

4. (continue). This rule tells that when the computation task in leaf mode 
is not finished in a period, it will continue its task in the next period. In 
this case, the system is implicitly not allowed to switch to other modes 
from the current mode. When moving to the next period, sensor detection 
is skipped. 

5. (repeat). This rule specifies the behavior of restarting the flow graph 
when the computation task is finished in a period. When it is at the end 
of a period and the system finishes executing the flow graph (pc — Exit), 
if there is no transition guard enabled, the system stays in the same mode 
and restarts the computation specified by the flow graph. 
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] 



7' 



< 100ms 



A failure occurs 



Mode Switch 



Figure 3: A Property about Failure 



Terms 8 = r \ v \ I \ f{9\, ■ ■ ■ , n ) 

Formulas <fi,ip = tt \ ff \ p(9\ , . . . , 8 n ) \ ~^<fi I <t> A ip \ 4^^> 

Figure 4: The Syntax of ITL 

6. (switch). This rule specifies the behavior of the mode transition. There 
exists a transition t, whose guard holds on the sequence of states E. And 
the priority of t is higher than that of any other enabled transitions. 

3 The Property Specification Language 

We adopt the Interval Temporal Logic (ITL) [13] as the property specification 
language. The reason why we adopt the interval-based logic instead of state- 
based logics like LTL or CTL is that most of the properties the domain engineers 
care about are related to some duration of time. For instance, the engineers 
would like to check if the system specified by MDM can stay in a specific state 
for a continuous period of time instead of just reaching this state. Another 
typical scenario illustrated in Fig. [3] is that, "when the system control is in 
mode ?Ti4, if a failure occurs, it should switch to mode in 100 ms". The 
standard LTL formula \3(failure A 7714 => Oms) can be used to specify that 
"when the system is in mode mi, and a failure occurs, it should switch to mode 
ms" ■ But the real-time feature "in 100 ms" is lost. Though the extended LTL 
or CTL may also describe the interval properties to some extent, it is more 
natural for the domain engineers to use interval-based logic since the intuitive 
chop operator (") is available in ITL. 

An interval logic formula can be interpreted over a time interval [J] or over a 
"state interval" (a sequence of states) [13] . As explained later in this section, 
our proposed specification language will be interpreted in the latter way [13) 
except for a small modification on the interpretation of the chop operator ("). 



The syntax of the specification language is defined in Fig [4] where 

• The set of terms contains real-value constants r, temporal variables v, 
a special variable I, and functions f{0\, . . . , n ) (with / being an n-arity 
function symbol and 6\, . . . , 9 n being terms). 



3.1 Syntax 
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Xr(r,E) =r 

cr n _i(ts) — cro(ts) if E = (J <x„_i 

oo if I E |= oo 

T T {v, cr .E) = o-o(w) 

Xr(/(fi, ■ • • , E) = / (Z r (0i, E), . . . ,T T (9 n , E)) 



l T (l, E) = 



Ijr(p(0i,...,d„),E) = true 


iff 


p(2r(0i,E),.-.,Zr(0n,£)) 


Xjr(tt,E) = true 


iff 


always 


= false 


iff 


always 


2f(^0,E) = true 


iff 


It{4>, E) = false 


If((/)A(/i,S) =true 


iff 


Zf(0, S) = true and Ij^(ip, E) = true 


Tj? (</>'" if), E) = true 


iff 


3fc < oo ■ E = (<T • • • fffc • E')A 



Ir{4>, (jo ... crfc) = true A It{^, E') = true 
Table 3: Interpretation of the Specification Language 



• Formulae can be boolean constants (tt, ff), predicates (p(9i, . . . ,9 n ) with 
p, an n-arity predicate symbol) , classical logic formulae (constructed using 
-i, A, etc), or interval logic formulae (constructed using ~~*). If the formula 
4>^ijj holds for an interval £, it means that the interval I can be "chopped" 
into two sub-intervals, where <f> holds for the first sub-interval and if) holds 
for the second one. 

As a kind of temporal logic, ITL also provides the □ and operators. They 
arc defined as the abbreviations of 



00 = tf{<f> tt), for some sub-interval , 0<f> = - i 0(~ [ (f>), for all sub- intervals 

By the specification language proposed here, we can describe the properties 
the domain engineers may desire. For instance, the following property describes 
the scenario shown in Fig. [3J 



D(m4 A {— 'failure^ failure)^ tt => 771,4 A (-1/ 'ailure^ {failure A I < 100))"t77s tt) 



3.2 Interpretation 

Terms/formulae in our property specification language are interpreted in the 
same way as in Maszkowski |13) , where an interval is represented by a finite or in- 
finite sequence of states (E = oqO\ . . . <r n _i . . .), where cr, G State. The interpre- 
tation is given by two functions (1) term interpretation :Xf G Termsx Intv n> R, 
and (2) formula interpretation function: Xjr £ Formulas x Intv 1— > {true, false}. 
Table [3J defines these two functions, where ts denotes the variable timestamp. 
The value of the variable timestamp increases with the elapse of the time, i.e., 
for any two states in the same interval o~i,Oj, if i<j, then <Ji(ts)<(Tj(ts). Thus, 
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we can compute the length of time interval based on the difference of the two 
time stamps located in the first and last states respectively. The interpretation 
of a variable v on E is the evaluation of v on the first state of E. Note that our 
chop operator requires that the first sub-interval of E is restricted to be finite 
no matter whether the interval E itself is finite or not. 

4 MDM Verification by Statistical Model Check- 
ing 

As a modelling & verification framework for periodic control systems, MDM 
supports the modelling of periodic behaviors, mode transition, and complex 
computations involving linear or non-linear mathematical formulae. Moreover, 
it also provides a property specification language to help the engineers capture 
requirements. In this section, we will show how to verify that an MDM model 
satisfies properties formalized in the specification language. There are two main 
obstacles to apply classic model checking techniques on MDM: (1) MDM models 
involve complex computations like non-linear mathematic formulae; (2) MDM 
models are open systems which need intensive interactions with outside. 

Our proposed approach relies on the Statistical Model Checking(SMC) [T51 
[T51 IT21 [3] . SMC is a simulation-based technique that runs the system to gen- 
erate traces, and then uses statistical theory to analyze the traces to obtain 
the verification estimation of the entire system. SMC usually deals with the 
following quantitative aspect of the system under verification [19 : 

What is the probability that a random run of a system will satisfy the 
given property </>? 

Since the SMC technique verifies the target system with the probability 
estimation instead of the accurate analysis, it is very effective when being applied 
to open and non-linear systems. Since SMC depends on the generated traces 
of the system under verification, we shall briefly describe how to simulate an 
MDM and then present an SMC algorithm for MDM. 

4.1 MDM Simulation 

The MDM model captures a reactive system [8]. The MDM model executes and 
interacts with its external environment in a control loop in one period as follows: 
(1) Accept inputs via sensors from the environment. (2) Perform computational 
tasks. (3) Generate outputs to drive other components. The MDM simulation 
engine simulates the process of the control loop above. 

Generally speaking, the simulation is implemented according to the inference 
rules defined in Table [2j However, the behaviors of an MDM model depends 
not only on the MDM itself, but also on the initial state and the external envi- 
ronment. When we simulate the MDM model, the initial values are randomly 
selected from a range specified by the control engineers from CAST. To make 
the simulation executable, we have to simulate the behaviors of the environment 
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input 



md: the MDM, 4>: property, B: bound of periods 
5: confidence, e: approximation 

p: the probability that holds on an arbitrary run of md 



output 
begin 



10 
20 
30 
40 
50 
60 
70 



N := 4* a := 



for i := 1 to AT do 

generate an initial state sq randomly 

simulate the MDM from so in B periods to get the state trace £ 
if (2jr(</>, S) = true) then a := a + 1 



end for 
return 



end 



Figure 5: Probability Estimation for MDM 



to make the MDM model to be closed with its environment. The environment 
simulator involving kinematical computations designed by the control engineers 
is combined with the MDM to simulate the physical environment the MDM 
model interacts with. In the end of each period, the guard of transitions is 
checked. The satisfaction of duration and after guards does not only depend on 
the current state, but also the past states. The simulator sets a counter for each 
duration/after guard instead of recording the past states. As a MDM model is 
usually a non-terminating periodic system, the bound of periods is set during 
the process of simulation. 



We apply the methodology in [19] to estimate this probability that a random 
run of an MDM will satisfy the given property <f> with a certain precision and 
certain level of confidence. The statistical model checking algorithm for MDM is 
illustrated in Fig. [5] Since the run of the MDM usually is infinite, the users can 
set the length of the sequence by the number of periods based on the concrete 
application. This algorithm firstly computes the number N of runs based on the 
formula N :— A* log(l/<5) / e 2 which involves the confidence interval [p — 5, p + S] 
with the confidence level 1 — e. Then the algorithm generates initial state (line 
30) and gets a state trace E by the inference rules defined in Table (line 40). 
The algorithm in line 50 decides whether <f> holds on the constructed interval 
based on the interpretation for the specification language mentioned in Section[3l 
If the interpretation is true, the algorithm increases the number of traces on that 
property <j) holds. Line 70 returns the probability for the satisfiability of cf> on 
the MDM. 



4.2 SMC Algorithm 
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5 Case Study and Experiments 

We have implemented the MDM modeling and verification framework and ap- 
plied it onto several real periodic control systems. And two of them (termed 
hereafter as A and B) are for spacecraft control developed by Chinese Academy 
of Space Technology (CAST), where the system B is an updated version of A. 
The system A has been launched successfully while system B was under develop- 
ment when we conducted the study with CAST. The engineers in CAST would 
like to check if the system B is correctly updated. Both of the two systems have 
17 modes (6 sub-modes). Mode m4 and mode ml have sub-modes. Mode m4 
has three sub-modes, G0,G1 and G2. Mode ml also has three sub-mode, 51, 
55 and 510. Fig.[T]is a small portion of the MDM model for system B. 

During the modeling phase by MDM, some existed ambiguities are detected 
in the requirement documents for both system A and B. For instance, the 
designers do not specify the priorities on the transitions between modes, while 
the engineers implement the priorities based on their experiences. However, 
priority in MDM is a mandatory option, which could avoid the ambiguities for 
the transitions. 

During the verification phase by the statistical model checking on MDM, two 
design defects in system B are uncovered by analyzing the verification results: 
(1) A variable is not initialized properly. (2) A value from sensors is detected 
from the wrong hardware address. In the traditional developing process in 
CAST, these two defects may be revealed only after a prototype of the software 
is developed and then tested. Our approach can find such bugs in design phase 
and reduce the cost to fix defects. In the following, we explain the experiments 
on the verification in more detail. 

5.1 Verified Properties 

We communicate with the engineers in CAST, summarize several properties 
the two classes of spacecrafts should obey, and present these properties in our 
specification language. A total of 12 properties are developed by the engineers 
and these properties are verified on the systems A and B. We only highlight 
three properties because the verification results on these three properties are 
different for systems A and B, which reveal two defects. 

Property 1 The system will eventually reach the stable state forever 



where uj x , u> x anduj z are angles. <J X) w x andw z are angle rates. 

Property 2 The system starts from mode mO, and then it will finally switch 
to mode m5 or m6 or m8, and stay in one of these three mode forever 




(mode = 0)^tf~D(mode = 5 V mode — 6 V mode = 8) 
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Figure 6: The Probabilities Curve 

Property 3 Whenever the system switches to mode to4 and then leaves mA, 
during it stays in mA, it firstly stays in sub-mode GO, and then it switches to 
sub-mode Gl, and then G2. 

D(mode ^ 4^ mode = 4" mode ^ 4 => mode ^ 4" 
mode = 4 A (gm = 0~~ gm = l^gm = 2)""tt) 

5.2 Experimental Results 

For the parameters of the statistical model checking algorithm, we set the half 
length of confident interval to be 1% (8 = 1%) and the error rate to be 5% 
(e = 5%). Based on this algorithm, the total 7369 traces for each control 
system are required to be generated to compute the probabilities during the 
verification process. We also compute the probabilities under different period 
bounds based on the traces, from 500 periods to 5000 periods (the maximum 
bound 5000 is suggested from the engineers of CAST). 

The average verification time for each property is about 5.4 hours (5000 pe- 
riods). The maximum verification time for one property is 8.6 hours and the 
minimum verification time is 3.5 hours (5000 periods). The experiments are con- 
ducted on a workstation with eight-core Intel(R)Xeon(R) CPU E5345@2.33GHz, 
16GB RAM and Windows Server 2003 operation system. 

Twelve properties are all passed for system A, and nine of twelve properties 
are passed for system B. Take the example for system A, the probabilities of 
properties PI and P2 increase from 0% to 100% with the periods bound from 
500 to 5000, which means it takes a couple of periods for the system to reach 
a stable state. Given more periods, the probability of stability is higher. The 
probabilities of P2 are similar to those of PI. We communicate with the en- 
gineers and they confirm that the experimental results PI and P2 conform to 
the control theory, 

The experimental differences for systems A and B are for properties P1,P2 
and P3, which are shown in Fig. [6] From this figure, we can see: 

1. The probability of PI in B also increases with the increasing of period. 
But it increases more slowly in B than in A, and it only reaches 92% most 
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in the given period bound, which means control system B needs to take 
longer than what the control system A does to reach a stable state. 



2. For system B, the property P2 is not satisfied, for all the probabilities 
are 0% in any period bound. But for system A, the probability of this 
property increases from 0% to 100%. 

3. For system B, the probability of property P3 decreases from 100% to 27% 
with the increment of period bound, while for system A, the probability 
of this property keeps 100% in any period bound. 

We communicate with the engineers from CAST to investigate why the ver- 
ification results of system A and B are different. For property PI, we find that 
the difference is caused by the unexpected value of a global variable x. The 
value of x of system B is detected to be out of the specified range in some cases 
by analyzing the traces. In system A, before x is used, its value is assigned by 
calling a preprocessing function. But in system B, the preprocessing function 
call is moved to a module which cannot be ensured to be called before using the 
variable x. As a result, x is probably given a value outside the specified range, 
which leads to the slow arrival of the stable state in system B. 

For property P2, by analyzing the traces of system B we find the system 
never enters modes m5, m6 and m8 from mode m4 and it stays in sub- mode Gl 
of mode m4 finally, which leaves the property P2 never satisfied. The reason 
for leading to this problem is that the value of a variable y is invalid. By the 
exploration of system B, we find that value of y is still being assigned from the 
old hardware address while it should be obtained from the new one because the 
old bus is updated to a new one in system B. The engineers ignore the change 
in the design of system B when updating it from system A. 

For property P3, we find the reason for that the probability of P3 decreases 
from 100% to 27% is that when the period bound is short, the system does not 
switch to mode 4 at all, which makes the property P3 hold since its premise 
mode 7^ 4^ mode = 4" mode ^ 4 is unsatisfied. With the increment of period 
bound, the system may switch to mode 4 in some cases but cannot reach the sub- 
mode G2, so the probability of P3 decreases. The reason of the unreachability 
of sub-mode G2 is the same with the one leading to the unsatisfiability of the 
property P2. 

6 Related Work 

Our MDM can be broadly considered as a variant of Statecharts [7], where a 
mode in MDM is similar to a state in the Statecharts. However, we note the 
following distinctions: (1) In Statecharts, when a transition guard holds, the 
system immediately switches to the target state. But in MDM, mode switches 
are only allowed to be triggered at the end of a period. (2) In Statecharts, a 
transition guard is usually a boolean expression on the current (source) state; 
while in MDM, transition guards may involve past states via predicates like 
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during and after. (3) In Statccharts, all observations on the system are the 
states; while MDM also concerns about the computation aspect of the system 
by means of the flow graphs provided in the leaf modes. 

Giese et al. [5] have proposed a semantics of real-time variant of Statecharts 
by introducing the Hierarchical Timed Automata. In another work [B] they have 
presented a compositional verification approach to the real time UML designs. 
A. K. Mok et al. have developed a kind of herarchical real-time chart named 
"Modechart" [TT] . Compared with Giese et al. [5] , parallel modes are supported 
in Modechart. Stateflow is the Statechart-like language used in the commer- 
cial software Matlab/Simulink pQ. The Stateflow language enriches Statecharts 
to allow it to support flow-based and state-based computations together for 
specifying discrete event systems. Our MDM focuses more on periodic control 
systems, which can be regarded as a specific type of discrete event systems, 
and it provides the first class element period to facilitate the precise modeling 
of periodic-driven systems. The transitions in Stateflow can be attached with 
a flowchart to describe complicated computation, the MDM specifies the flow 
graph for the computation in its leaf modes. While Stateflow focuses only on the 
modelling aspect of the systems, the MDM integrates modelling and reasoning 
by providing a property specification language and a verification algorithm. 

Some researchers introduce operational mode [141 115] during the modeling 
in hardware/software consynthesis. The operational mode is essentially a state 
in the automata, but it can be attached a flowchart for the description of the 
computation. It does not support the nested mode and period explicitly. How- 
ever, it is actually an informal modeling notation because it allows to specify 
the system behaviors in the natural langauge. Our ModeChart is a lightweight 
formal notation for the modeling with its precise operational semantics. 

Giotto is also a periodic-driven modeling language proposed by Henzinger et 
al. [10] . The main difference between Giotto and MDM is about the computation 
mechanism provided. The tasks in a mode can be performed in parallel in Giotto 
while the details of the tasks are omitted and are moved to the implementation 
stage. The MDM supports the detailed description of the computation in their 
leaf modes since the design of it is targeted for control systems which may 
involve rich algorithms. The MDM does not support the parallel computation 
explicitly at present since it could bring the nondctcrminism at the design level. 
The emphasis of the Giotto is more the modeling and synthesis of parallel tasks 
while the MDM is for the modeling and verification based on the proposed 
specification language. 

Runtime Verification is a verification approach based on extracting informa- 
tion by executing the system and using the information to detect whether the 
observed behaviors violating the expected properties [5J [T7] . The verification 
approach we apply in this paper is also a kind of runtime verification. But our 
methodology is the off-line analysis, while [T7] applies an on-line monitoring 
approach using Aspect-J. The reason to propose off-line analysis is that the cost 
to decide if an ITL formula is satisfiable on a given trace is huge, so information 
extraction and analysis are separated to two phases in our approach. 
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7 Conclusion 



In this paper, we propose the Mode Diagram Modelling framework (MDM), a 
domain-specific formal visual modelling language for periodic control systems. 
To support formal reasoning, MDM is equipped with a property specification 
language based on interval temporal logic and a statistical model checking algo- 
rithm. The property specification language allows engineers to precisely capture 
various properties they desire, while the verification algorithm allows them to 
reason about MDM models with respect to those properties. The viability and 
effectiveness of the proposed MDM framework have been demonstrated by a 
number of real life case studies (two of which have been presented in the paper), 
where defects of spacecraft control systems have been detected and uncovered 
in the early design stage. 
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